Release 10.1A: OpenEdge Getting Started:
Object-oriented Programming


Class hierarchies and procedure hierarchies

A class can inherit from (extend) only one other class. However, a class can be extended by any number of other classes. A class hierarchy represents all the classes that a class inherits either directly or indirectly through multiple levels of inheritance. The root of a class hierarchy is a class that does not extend any other class. The entire class hierarchy is treated as a single user-defined data type. You can logically think of a class as the merging of its own data members and methods with all of the non-private data members and methods of all the classes above it in the hierarchy, plus the built-in data members and methods of the root class, Progress.Lang.Object.

To illustrate this, consider the hierarchy for these sample classes (see the "Sample classes" section), where acme.myObjs.Common.CommonObj is the top user-defined super class, acme.myObjs.CustObj inherits from acme.myObjs.Common.CommonObj, and acme.myObjs.NECustomer inherits from acme.myObjs.CustObj, represented as follows:

Progress.Lang.Object                   <--- Top of hierarchy 
    acme.myObjs.Common.CommonObj 
        acme.myObjs.CustObj 
            acme.myObjs.NECustomer    <--- Bottom of hierarchy 

A class definition can override a method in its class hierarchy by providing a method definition with the same name, return type, access mode, number of parameters, and corresponding parameter types as the method in its class hierarchy. It also must use the OVERRIDE keyword on the overriding definition so the compiler knows that the override is your deliberate action. For example the acme.myObjs.CustObj class can have a method GetCustomerName( ) that returns the name of a customer. The acme.myObjs.NECustomer class can override the GetCustomerName( ) method to provide both the name and E-mail address for the customer.

Comparison with procedure-based programming

There are parallels between a class hierarchy and the super procedure mechanism in Progress. Super procedures provide some aspects of inheritance and delegation. For example, if the classes acme.myObjs.Common.CommonObj, acme.myObjs.CustObj, and acme.myObjs.NECustomer were implemented as Progress procedures, then the startup code for NECustomer.p could run CustObj.p and CommonObj.p persistently, and use the ADD-SUPER-PROCEDURE built-in method to create a super procedure chain linking the three running procedure instances. The procedures could implement some of the same internal procedures or functions, and pass control from one level to the next higher level using the RUN SUPER statement or the SUPER built-in function. As described in a previous section, a key aspect of this technique is that all the associations are established at run time, so that the Progress compiler has no opportunity to validate the correctness of references between the procedures.

Class inheritance provides this functionality through more conventional object-oriented syntax, in a framework of strong typing and compile-time validation. Using one technique or the other is a choice that you have to make when you begin the design of an application module that is made up of multiple related procedures or classes. Whatever your choice, you cannot use the super procedure mechanism in classes, and you cannot build a class hierarchy from procedures.


Copyright © 2005 Progress Software Corporation
www.progress.com
Voice: (781) 280-4000
Fax: (781) 280-4095